Skip to content

fix(certifier): check wire message size before JSON deserialisation #1523

Open
atharrva01 wants to merge 3 commits intohyperledger-labs:mainfrom
atharrva01:fix/certifier-comm-stack-size-guard
Open

fix(certifier): check wire message size before JSON deserialisation #1523
atharrva01 wants to merge 3 commits intohyperledger-labs:mainfrom
atharrva01:fix/certifier-comm-stack-size-guard

Conversation

@atharrva01
Copy link
Copy Markdown
Contributor

@atharrva01 atharrva01 commented Apr 10, 2026

Closes #1557

Follow-on to #1498 based on your @adecaro's review feedback.

The MaxRequestBytes check I added in #1498 ran after full JSON deserialization , so a 500 MiB payload would still spike the heap before getting rejected. The fix needs to happen earlier.

I can't touch the transport layer directly, but ReceiveRaw() gets us close enough: now we check len(raw) > MaxWireMessageBytes before ever calling json.Unmarshal, so an oversized message gets dropped before any allocations for the IDs slice or Request field.

To keep this unit-testable without a real FSC session, I added a sessionFactory field (defaults to session.JSON) so tests can inject a fake that returns preset raw bytes.

Changes:

  • config.go , adds MaxWireMessageBytes = MaxRequestBytes * 2
  • service.go , switches to ReceiveRaw + size guard + manual unmarshal; adds sessionFactory
  • service_test.go , 4 new tests: oversized reject, at-limit pass-through, transport errors, constant relationship

Adds MaxWireMessageBytes (2 MiB) and uses ReceiveRaw() to reject
oversized messages before json.Unmarshal, preventing heap spikes from
allocate-then-reject. Injects sessionFactory for unit testability.

Signed-off-by: atharrva01 <atharvaborade568@gamil.com>
@atharrva01
Copy link
Copy Markdown
Contributor Author

caught oversized payloads before deserialization using ReceiveRaw + size guard, cc @adecaro

Signed-off-by: atharrva01 <atharvaborade568@gamil.com>
@AkramBitar
Copy link
Copy Markdown
Contributor

@atharrva01 thanks a lot for opening the PR.
Could you please open an issue and link it to this PR?

Also, could you please have a look at the failing tests?

@adecaro
Copy link
Copy Markdown
Contributor

adecaro commented Apr 15, 2026

Hi @atharrva01 , thanks for the effort.
I'm not convinced by this one. I need we need a more systematic way to address these kind of issues without having to modify each view. For instance, a way to inject this limit in the comm stack of the smart client could be very helpful.
What do you think?

…sion

Create session.SizeLimitedJsonSession, a JsonSession wrapper that enforces
a configurable byte limit on every received message before JSON decoding.
Expose it via session.NewSizeLimitedSession and session.JSONWithLimit so
any view can opt in without duplicating the size-check logic.

CertificationService now defaults its sessionFactory to JSONWithLimit, and
Call() reverts to the simpler s.Receive() call — the guard is transparent.

Signed-off-by: atharrva01 <atharvaborade568@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug(audit): zkatdlog AuditorCheck validates transfer inputs against action-embedded tokens, not ledger commitments

3 participants